BGP uses update messages to communicate information between two BGP speakers. The update message can advertise a single feasible route to a peer, or withdraw multiple unfeasible routes from service.
The following figure shows the format of an update message.
This section describes how BGP uses the update message fields to communicate information between BGP speakers.
The withdrawn routes length parameter (referred to in RFC1771 as the Unfeasible Routes Length field) indicates the total length of the withdrawn routes field in octets. The withdrawn routes length field calculates the length of the NLRI field. For example, a value of 0 indicates that no routes are withdrawn from service, and that the withdrawn routes field is not present in this update message.
The withdrawn routes parameter is a variable-length parameter that contains a list of IP prefixes for routes that are withdrawn from service. The following figure shows the format of an IP prefix.
The length indicates the number of bits in the prefix (also called the network mask).
For example, 192.0.2.0/24 is equivalent to 192.0.2.0 255.255.255.0 (the /24 indicates the number of bits in the length parameter to represent the network mask 255.255.255.0).
The prefix parameter contains the IP address prefix itself, followed by enough trailing bits to make the length of the whole field an integer multiple of 8 bits (1 octet).
The total path attributes length parameter indicates the total length of the path attributes parameter in octets.
The total path attributes length calculates the length of the NLRI parameter. For example, a value of 0 indicates that no NLRI field is present in this update message.
The path attributes parameter is a variable-length sequence of path attributes that exists in every BGP update. The path attributes contain BGP attributes associated with the prefixes in the NLRI parameter.
For example, the attribute values allow you to specify the prefixes that the BGP session can exchange, or which of the multiple paths of a specified prefix to use.
The attributes carry the following information about the associated prefixes:
the path origin
the AS paths through which the prefix is advertised
the metrics that display degrees of preference for this prefix
The following figure shows the encoding used with the path attribute parameter.
As shown in the following figure, the attribute type is a two-octet field that comprises two sub-fields: attribute flags and attribute type code.
The attribute flags parameter is a bit string that contains four binary values that describe the attribute, and four unused bits. The following list provides bit descriptions (from the high-order bit to the low-order bit):
The high-order bit (bit 0) is the optional bit. When this bit is set (the value is 1), the attribute is optional. When this bit is clear (the value is 0), the attribute is well-known. Well-known attributes must be recognized by all BGP implementations and, when appropriate, passed on to BGP peers. Optional attributes are not required in all BGP implementations.
The second high-order bit (bit 1) is the transitive bit. For well-known attributes, this bit must be set to 1. For optional attributes, it defines whether the attribute is transitive (when set to 1) or non-transitive (when set to 0).
The third high-order bit (bit 2) is the partial bit. The partial bit defines whether the information in the optional transitive attribute is partial (when set to 1) or complete (when set to 0). For well-known attributes and for optional non-transitive attributes the partial bit must be set to 0.
The fourth high-order bit (bit 3) is the extended length bit. The extended length bit defines whether the attribute length is one octet (when set to 0) or two octets (when set to 1). The attribute flag can use the extended length only if the length of the attribute value is greater than 255 octets.
If the extended length bit of the attribute flags octet is set to 0, the third octet of the path attribute contains the length of the attribute data in octets.
If the extended length bit of the attribute flags octet is set to 1, then the third and the fourth octets of the path attribute contain the length of the attribute data in octets.
The lower-order four bits of the attribute flags octet are unused. The lower-order four bits must be zero (and must be ignored when received).
The attribute type code parameter contains the attribute type code, as defined by the Internet Assigned Numbers Authority (IANA). The attribute type code uniquely identifies the attribute from all others. The remaining octets of the path attribute represent the attribute value and are interpreted according to the attribute flags and the attribute type code parameters.
The following table shows the supported attribute type codes.
Attribute |
Type code |
Description |
---|---|---|
Origin |
1 |
Defines the origin of the path information:
|
AS path |
2 |
Contains a list of the autonomous systems that packets must traverse to reach the destinations. This code represents each AS path segment as follows:
|
Next hop |
3 |
Specifies the IP address of the border router to use as a next hop for the advertised destinations (destinations listed in the NLRI field of the update message). |
Multiexit discriminator |
4 |
Discriminates among multiple exit or entry points to the same neighboring AS on external (internal-AS) links. |
Local preference |
5 |
Indicates the preference that AS border routers assign to a chosen route when they advertise it to iBGP peers |
Atomic aggregate |
6 |
Ensures that certain NLRI is not deaggregated |
Aggregator |
7 |
Identifies which AS performed the most recent route aggregation. This attribute contains the last AS number that formed the aggregate route followed by the IP address of the BGP speaker that formed the aggregate route. |
The attribute length can be one or two octets in length, depending on the value of the extended length parameter in the attributes flag field.
This parameter indicates the length of the attribute value field.
The attribute value contains the actual value of the specific attribute. The system implements the attribute value according to the values in the attribute flags and the attribute type code parameters.
The NLRI parameter is a variable length field that contains a list of prefixes. The packet size that BGP speakers can exchange limits the number of prefixes in the list.